git rebase 变基

1.看公司的策略。有的公司认为提交历史就是实际发生过的事件的记录。它是一个记载着历史的“史书”，自有其价值，而且不能随意篡改。从这个角度来说，是不允许更改提交历史，也就不能使用变基了。

2.还有另外一个角度是，提交历史是关于项目如何被构建的故事。就像我们写的软件，一定是整理好了才发出去，使得后来的人能够更好的理解项目的构建。这时候就推荐使用变基。

常用命令：
git rebase --continue 继续变基
git rebase --abort 终止变基

1，本地将多个提交合并为一个提交
启动交互式变基：
使用命令，指定要变基的基点（通常是当前分支的上游分支）。
git rebase -i HEAD~n,这里的 n 是你想要合并的提交数量。
会打开一个文本编辑器，显示最近的 n 个提交。你会看到每个提交前面有一个 pick 字段。
将你想要合并为一个提交的第一个提交保留为 pick，而将其他提交的 pick 更改为 squash（或简写为 s）。
squash <提交> = 使用提交，但融合到前一个提交
最后还可以重新编写提交说明
保存并关闭编辑器，Git 会开始变基过程，并将选定的提交合并为一个提交。
# goland 快捷操作
右击从这里进行交互式变基->选中文件->点压缩->点击启动编辑

2，多人使用同一个分支开发(未验证)
git push产生冲突，说明有人先你一步同步了他的本地代码到远程。
这时候，你需要先拉取代码，可以使用命令
git pull , 该命令会将远程的提交和你本地的提交merge，如果有冲突需要手动解决并提交，会产生merge的记录
git pull -- rebase 该命令会把你的提交“放置”在远程拉取的提交之后，即改变基础（变基），如果有冲突
解决所有冲突的文件，git add <冲突文件>
git rebase --continue
完美解决问题。

3，自己单独分支合并到主分支（要求本地的提交记录，都在master最新提交的后面）

要将本地分支 a 合并到 master 分支，并确保本地的提交记录都在 master 最新提交的后面，可以使用 git rebase。以下是具体的步骤：

1. 切换到 master 分支：

   git checkout master

   1	git checkout master

2. 确保 master 是最新的：
   从远程拉取最新的 master：

   git pull origin master

   1	git pull origin master

3. 切换到本地分支 a：

   git checkout a

   1	git checkout a

4. 对本地分支 a 进行变基：
   将 a 的提交放置在 master 的最新提交之后：

   git rebase master

   1	git rebase master

   • 如果在这个过程中出现冲突，解决冲突后使用 git add <冲突文件>，然后继续变基：
     
     git rebase --continue

     1	git rebase --continue

5. 切换回 master 分支：

   git checkout master

   1	git checkout master

6. 合并 a 到 master：
   使用快进合并（因为 a 已经在 master 之上）：

   git merge a

   1	git merge a

7. 推送到远程 master：
   最后，将合并后的 master 推送到远程：

   git push origin master

   1	git push origin master

总结

通过以上步骤，你可以确保本地分支 a 的提交记录都在 master 最新提交的后面，并且合并后的结果会保持提交历史的整洁。

注意事项：

在使用 git rebase 时，冲突的处理顺序是非常重要的。以下是关于冲突处理的详细说明：

1. Rebase 的过程

• 当你执行 git rebase <base> 时，Git 会逐个应用你在当前分支上的提交到 <base> 分支上。
• 如果在应用某个提交时遇到冲突，Git 会暂停 rebase，并提示你解决冲突。

2. 解决冲突的正确步骤

• 先进行 rebase：当你执行 git rebase 后，如果遇到冲突，Git 会停止并让你解决冲突。
• 解决冲突：在冲突发生时，你需要手动解决冲突，然后使用 git add <冲突文件> 来标记冲突已解决。
• 继续 rebase：解决完所有冲突后，使用 git rebase --continue 来继续应用后续的提交。

3. 如果先解决冲突再 rebase

如果你在执行 git rebase 之前手动解决了冲突，然后再执行 git rebase，那么这些冲突仍然可能会出现，因为 rebase 过程会尝试将你的提交一一应用到新的基础上。这意味着：

• 如果你在执行 rebase 之前已经解决了某些冲突，rebase 过程可能会再次遇到相同的冲突，尤其是如果你的基础分支（如 master）在你开始 rebase 之后发生了变更。

结论

• 正确的做法是：执行 git rebase 后，遇到冲突时解决冲突，然后继续 rebase。
• 不要在 rebase 之前手动解决冲突，因为这可能导致你在 rebase 过程中再次遇到相同的冲突。

这样可以确保你在 rebase 过程中处理冲突的方式是正确的，并且避免不必要的混乱。

————————————————

#git删除历史提交中的一个文件

如果多余的文件是在第一次提交中添加的，并且你希望从历史中彻底删除该文件，可以使用 git rebase 交互式模式来修改历史提交。
步骤 1：启动交互式 rebase
假设你有三次提交，可以使用以下命令：
git rebase -i HEAD~3
这会打开一个编辑器，显示最近三次提交的记录，例如：
pick commit1 第一次提交
pick commit2 第二次提交
pick commit3 第三次提交
步骤 2：修改提交
找到包含多余文件的提交（假设是第一次提交），将其行的 pick 改为 edit：
edit commit1 第一次提交
pick commit2 第二次提交
pick commit3 第三次提交
步骤 3：删除文件并修改提交
Git 会停在第一次提交的位置。此时可以删除多余的文件：
git rm <file-path>
将更改追加到当前提交：
git commit --amend
继续 rebase 过程：
git rebase --continue
步骤 4：完成
多余的文件已从第一次提交中移除，后续提交会基于修改后的历史重新应用。

#多个提交变为一个提交
启动交互式变基：
假设你想要压缩最近的 3 个提交，可以使用以下命令：
git rebase -i HEAD~3
这将打开一个文本编辑器，显示最近 3 个提交的列表。
编辑提交列表：
在打开的编辑器中，你会看到类似于以下的内容：
pick abcdef1 Commit message 1
pick abcdef2 Commit message 2
pick abcdef3 Commit message 3
将第二个和第三个提交的 pick 改为 squash（或简写为 s）：
pick abcdef1 Commit message 1
squash abcdef2 Commit message 2
squash abcdef3 Commit message 3
保存并关闭编辑器：
保存文件并关闭编辑器。Git 将会开始变基过程，并尝试将这些提交合并成一个。
编辑合并后的提交信息：
接下来，Git 会打开另一个编辑器窗口，让你编辑合并后的提交信息。你可以选择保留所有提交的信息，或只保留你想要的内容。编辑完成后，保存并关闭编辑器。
完成变基：
如果没有冲突，变基将会成功完成，多个提交将被合并为一个。